DVMLIB
--------
DVMLIB is a utility which will scan a .DVM application identifying the
instructions which invoke DVM's built-in internal library.

These can be can be patched to use a different internal library layout.
This is useful if you don't have the source code to a .DVM application and
wish to use it under a version of DVM where the library layout has changed.

I make an effort NOT to change the library layout in my free version, but
in the event of an update where less used functions are removed, such
changes may still occur.  For anyone using a version where you are creating
your own library, it will likely change from mine initially, and DVMLIB
can allow you to continue using my applications on your new version.

To see what library calls (if any) have actually changed, compare the
LIBDVM\MCCILIB.CFG files from the two versions.


DVMLIB needs three input files:

Application: This is a .DVM application that you wish to translate.

OLDmccILIB: This is the MCCILIB.CFG file which reflects the original
  library layout.

mccILIB: This is the MCCILIB.CFG file which reflects the NEW
  library layout.

The ILIB files are used to work out the translations which are to be applied.
  These files are very simple, just a function NAME and an internal library
  call number. For an example .ILIB file, see my Micro-C DVM compiled (also
  available as a free download).'

  DVMLIB builds a table to translate library calls from OLD to NEW by matching
  them up by name.  The new library must have names which match the old for
  any functions which are used/translated.  When the ILIB file has multiple
  names for a given library call number, DVMLIB uses the first one occurring
  in the file.
 

How it works
------------
DVMLIB knows the DVM instruction set, and treats them as if it were
executing them, thereby hitting every instruction.  As it encounters
each instruction, it examines it to see if it is a call to the library.

DVMLIB does not actually execute the code, but it traverses the program
as if it were.  Where instructions have more than one "next" instruction
(CALL, SWITCH, conditionals etc.), DVMLIB will proceed down one path, and
mark the first instruction(s) of all possible other paths as "pending", so
ot will pick it up on another pass.

DVMLIB does not try to track stacked addresses, RETurn simply causes it
to stop.  Whenever it stops, it scans the image for any instructions marked
as "pending".  It then proceeds from there until it finds another reason to
stop and the process repeats until no pending instructions remain.  Each
session where it starts at a "pending" instruction is called a PASS and you
will see that it typically runs a LOT of passes, basically handling all
possible conditional execution within a program.

DVMLIB does know about SWITCH tables, and will mark the code for each CASE
as pending.


What it does NOT do
-------------------
DVMLIB does NOT handle calls to computed addresses (via pointers) since
it is not executing the code, and therefore does not have the computed
address.  This won't be a problem if the function so called is also called
"normally", but it can miss functions which are only called by computed
addresses.

NONE of the tools and utilities I supply with DVM use calls to computed
addresses in this way.
